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What do we mean? 



« Damian's PBP has 256 items! 
& Not enough time to cover here 
& It would cut into Cinco De Mayo 

# Luckily, he selected 30 of the most essential 

# Ten each of: 

# Essential Development Practices 
« Essential Coding Practices 
0 Essential Module Practices 
& We'll start with those 



Essential Development 

Practices 



& How do we design our code? 
• Luckily, most of this isn't necessarily Perl 
specific 

& Not a lot of code examples here 



Design the module's 
interface first 



& A bad interface makes a module unusable 
0 Think about how your module will be used 
0 Name things from the user's perspective 

& Not from how it's implemented 
& Create examples, or even xx use cases" for your 

interface 

0 Keep the examples around for your 
documentation! 



Write tests first 



• Turn your examples into tests 
& Create the tests before coding 
« Run the tests, which should fail 
& Code (correctly!) 
« Now the tests should succeed 
0 Tests are also documentation 
0 So, comment your tests 



Create POD templates 



& Understand the standard POD 

& Enhance it with local standards 

• Don't keep retyping your name and email 

& Consider Module::Starter 



Use revision control 



0 Essential for team programming 
& But even good for one person 
d Great for sharing updates 

• Helpful for^when did it break" 

« And more importantly *who broke it" 

• Also prevents potential loss from hardware 
failures and human failures 



Use consistent APIs for 
arguments and config 



0 Require a flag in front of every arg, except 

filenames 
• Always allow as a filename 
0 Always use vx — " to indicate "end of args" 
0 Consider Config::General or Config::Std 
0 Allow user changes to be rewritten to the 

configuration file for the next run 



Use a consistent layout 



& Pick a style, and stick with it 

& Use perltidy to enforce it 

# But don't waste time reformatting everything 

& Life's too short to get into fights on this 



Code in commented 
paragraphs 



• Whitespace between chunks is helpful 
0 Chunk according to logical steps 

# Interpreting @_ separated from the next 
step in a subroutine 

« Add leading comments in front of the 

paragraph for a logical-step description 
0 Don't use comments for user docs, use POD 



Throw exceptions instead 

of funny returns 



& People might forget to test for *undef " 

& But they have to work pretty hard to ignore 

an exception 
• Exceptions can be easily caught with eval {} 
& Exceptions can be structured with 

Exception::Class 



Add new test cases 
before debugging 



& A bug report is a test case! 
& Add it to your test suite 
0 (You do have a test suite, right?) 
& Then debug. 

# You'll know the bug is gone when the test 
passes 

a And you'll never accidentally reintroduce that 
bug! 



Don't optimize until you 

benchmark 



0 Get the code right first 

0 Then make it go faster, if necessary 

& Use the tools 

• Benchmark 

« Devel::DProf 

0 Devel::SmallProf 



Essential Coding 
Practices 



0 Now that we've seen development 
& Lets go on to coding... 



Use strict 



& Barewords in the wrong place: 

my ©months = (jan, feb, mar, apr, may, jun, 
jul, aug, sep, oct, nov, dec); 
• Variables that are probably typos: 

my $bamm_bamm = 3; .... $bammbamm; 
& Evil symbolic references: 

$data{fred} = %x flintstone"; ... 

$data{fred}{age} = 30; 
& You just set $flintstone to 30! 



Use warnings 



0 *use warnings" catches most beginner 
mistakes 

« Beware *-w" on the command line 

0 Unless you want to debug someone else's 

mistakes when you use a module 
0 Reduce warnings for troublesome spots: 

& { no warnings Vedefine'; ... } 



Use grammar-based 

identifiers 



0 Packages: Noun :: Adjective :: Adjective 

0 Disk::DVD::Rewritable 
0 Variables: adjective_adjective_noun 

0 $estimated_net_worth 
0 Lookup vars: adjective__noun_preposition 

• %blocks_of, @sales_for 
0 Subs: imperative_adjective_noun[_prep] 

0 get_next_cookie, eat_cake 

0 get_cookie_of_type, eat__cake_using 



Use lexicals, not package 

variables 



& Lexical access is guaranteed to be in the 
same file 

& Unless some code passes around a reference 
to it 

& Package variables can be accessed anywhere 
0 Including well-intentioned but broken code 



Label loops used with 
last/next/redo 



« last/next/redo provide a limited *goto" 

• But it's still sometimes confusing 

• Always label your loops for these: 

LINE: while (<>) { ... next LINE if $cond; ... } 
« The labels should be the noun of the thing 

being processed 
9 Makes *last LINE" read like English! 



Don't use bareword 

filehandles 



& Use indirect filehandles (in modern Perl): 
& open my $foo, V, $someinput or die; 

0 They close automatically 

& Can be passed to/from subroutines 

& Can be stored in aggregates 

& Might need readline() or print {...} though 
• my $line = readline $inputs[3]; 
0 print { $output_for{$day} } ©list; 



Unpack @_ into named 

variables 



a $_[3] is just ugly 

a Even compared to the rest of Perl 

a Unpack your args: 

a my ($name, $rank, $serial) = @_; 
• Use 'shift" form for more breathing room: 

• my $name = shift; # %x Flintstone, Fred" 

• my $rank = shift; # 1..10 

a my $serial = shift; # 7-digit integer 



Use named parameters if 
more than three 



& Three positional parameters is enough 
& For more than three, use a hash: 

a my %options = %{+shift}; 

• my $name = $options{name} II die t?"; 
& Pass them as a hashref: 

« my_routine({name => %x Randal"}) 
• This catches the odd-number of parameters 

at the caller, not the callee. 



Always use explicit 

return 

0 Perl returns the last expression evaluated 
0 But make it explicit: 

0 return $this; 
0 Easier to see that the return value is 

expected 

0 Protects against someone adding an extra 
line to the subroutine, breaking the return 

0 Also use Veturn;" for undef /empty list 
return, not "return undef/' 



Use /xms and \A and \z 



a /x permits whitespace and comments 
a /m says xww ' and xx $" match embedded 
newlines 

a /s means xx ." really matches newline 

• \A is the old " 

a \z is the old $ 

a Except that it's really "end of string" 
a Not xx end of string but maybe before \n" 



Use capturing parens 
only when capturing 



0 Every (...) in a regex is a capture regex 

0 This affects $1, etc 

• But it also affects speed 

0 When you don't need to capture, don't! 

0 Use (?: ... ) 

0 Yes, a little more typing 

0 But it's clear that you don't need that value 



Name your captures 



& There can be quite a distance between 
• / (w+) \s+ (\w+) /xms 
0 $1, $2 

• Easy to make mistake, or modify and break 
things #' 

& Instead, name your captures when you can: 
« my ($given, $surname) = /(\w+)\s+(\w+)/ ; 

0 If this match fails in a scalar context, it 
returns false 



Export subroutines, not 

data 



a Yes, lets create a module, but then 

reintroduce global variables 
a OK, that's a bad idea 

• Variables have only get/set interface 

« And very little checking (unless you *tie") 
0 Export subroutines to give more control 

• And more flexibility for the future 



Essential Module 
Practices 



0 Once you get above 100 lines or so, modules 

are essential 
0 The unit of reuse of coding 
0 Modules also generally involve other people 
0 So its good to get it right 
0 Lets look at some practices... 



Use Test: More 



& Testing testing testing! 
0 Don't code your tests ad-hoc 
& Use the proven Perl framework 
# %x perldoc Test: Tutorial" 
& For local things, create additional Test::* 
mixins 



Create constants with 
the Readonly module 

0 Don't use %x constant", even though it's core 

• use constant PI => 3; 

0 You can't interpolate these easily: 

• print xx In indiana, pi is @{[PI]}\n"; 

• Instead, get Readonly from the CPAN: 

0 Readonly my $PI => 3; 
0 Now you can interpolate: 

• print xx In indiana, pi is $PI\n"; 
0 Yeay 



Use the semi-builtins in 
Scalar::Util and List::Util 

0 These are core with modern Perl 

• Scalar::Util has: blessed, refaddr, reftype, 
readonly, tainted, openhandle, weaken, 
is_weak, looks_like_number 

• List::Util has: first, max, maxstr, min, minstr, 
shuffle, sum, reduce 

& reduce is cool: 

« my $factorial = reduce { $a * $b } 1..20; 
• my $commy = reduce { xx $a, $b" } ©strings; 



Use IO::Prompt for 

prompting 



• Get it from the CPAN 

• my $line = prompt xx line, please? "; 
0 Automatically chomps (yeay!) 

• my $password = prompt ''password:", 

-echo => '*'; 
0 my $choice = prompt 'letter', -onechar, 

-require => { 'must be [a-e]' => qr/[a-e]/ }; 

• Many more options 



Use Carp and 
Exception::Class 

0 Carp blames someone else 

& use Carp qw(croak); 

... open my $f, $file or croak xx $file?"; 
• Use Exception::Class for nice exceptions 
« Exception::Class-based exceptions capture 

caller and current filename/linenumber/ 

package 

0 They also stringify nicely for naive displays 
& Create hierarchies for classified handling 



Use Fatal to turn 
failures into exceptions 



0 Tired of forgetting x or die" on 'open"? 
& use Fatal qw(:void open); 

• * * 

open my $f, *BOGUS FILE"; # dies! 
« Yes, finally open does the right thing 
« Autodetects void context, so this still works: 

• unless (open my $f, *BOGUS") { ... } 



Use Data::Alias or 



Lexical::Alias 

0 Don't subscript more than once in a loop: 
• for my $k (sort keys %names) { 
if (is_bad($names{$k})) { 
print xx $names{$k} is bad"; ... 
& Instead, alias the value: 

« for my $k (sort keys %names) { 
alias my $name = $names[$k]; 
0 The $name is read/write! 
& Requires Data::Alias or Lexical::Alias 



Use Regexp::Common 



& Don't reinvent the common regex 

& Use the expert coding in Regexp::Common 

0 $number =~ /$RE{num}{real}/ 

& $balanced_parens =~ /$RE{balanced}/ 

0 $bad_words =~ /$RE{profanity}/ 

& Module comes with 175,000 tests! 



Use Class::Std or 



Object::InsideOut 



& Getting accessors and privacy correct can 

take special care 
• Use inside-out objects for safety and best 

development speed 
& Class::Std or Object::InsideOut 



Use Perl::Critic 



• Automatically test your code against various 

suggestions made here 
0 Can be configured to require or ignore 

guidelines 
0 Consider it vx lint for Perl" 



In summary 




